home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1993 / Internet Info CD-ROM (Walnut Creek) (1993).iso / inet / internet-drafts / draft-ietf-pppext-frame-relay-01.txt < prev    next >
Encoding:
Text File  |  1993-07-08  |  11.3 KB  |  443 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        W A Simpson
  8. Internet Draft                                                Daydreamer
  9. expires in six months                                          July 1993
  10.  
  11.  
  12.                            PPP in Frame Relay
  13.  
  14.  
  15.  
  16. Status of this Memo
  17.  
  18.    This document is the product of the Point-to-Point Protocol Working
  19.    Group of the Internet Engineering Task Force (IETF).  Comments should
  20.    be submitted to the ietf-ppp@ucdavis.edu mailing list.
  21.  
  22.    Distribution of this memo is unlimited.
  23.  
  24.    This document is an Internet Draft.  Internet Drafts are working
  25.    documents of the Internet Engineering Task Force (IETF), its Areas,
  26.    and its Working Groups.  Note that other groups may also distribute
  27.    working documents as Internet Drafts.
  28.  
  29.    Internet Drafts are draft documents valid for a maximum of six
  30.    months.  Internet Drafts may be updated, replaced, or obsoleted by
  31.    other documents at any time.  It is not appropriate to use Internet
  32.    Drafts as reference material or to cite them other than as a
  33.    ``working draft'' or ``work in progress.''
  34.  
  35.    Please check the 1id-abstracts.txt listing contained in the
  36.    internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
  37.    nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
  38.    current status of any Internet Draft.
  39.  
  40. Abstract
  41.  
  42.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  43.    transporting multi-protocol datagrams over point-to-point links.
  44.  
  45.    This document describes the use of Frame Relay for framing PPP
  46.    encapsulated datagrams.
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Simpson                  expires in six months                  [Page i]
  59. DRAFT                      PPP in Frame Relay                  July 1993
  60.  
  61.  
  62. 1.  Introduction
  63.  
  64.    Frame Relay [2] is a relative newcomer to the serial link community.
  65.    Like X.25, the protocol was designed to provide virtual circuits for
  66.    connections between stations attached to the same Frame Relay
  67.    network.  The improvement over X.25 is that Q.922 is restricted to
  68.    delivery of packets, and dispenses with sequencing and flow control,
  69.    simplifying the service immensely.
  70.  
  71.    PPP uses ISO 3309 HDLC as a basis for its framing [3].
  72.  
  73.    At one time, it had been hoped that PPP HDLC frames and Frame Relay
  74.    would co-exist on the same links.  Unfortunately, the Q.922 method
  75.    for expanding the address from 1 to 2 to 4 octets is not
  76.    indistinguishable from the ISO 3309 method, due to the structure of
  77.    its Data Link Connection Identifier (DLCI) subfields.
  78.  
  79.    When Frame Relay is configured as a point-to-point circuit, PPP can
  80.    use Frame Relay as a framing mechanism, ignoring its other features.
  81.    This is equivalent to the technique used to carry SNAP headers over
  82.    Frame Relay.
  83.  
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113. Simpson                  expires in six months                  [Page 1]
  114. DRAFT                      PPP in Frame Relay                  July 1993
  115.  
  116.  
  117. 2.  The Data Link Layer
  118.  
  119.    This specification uses the principles, terminology, and frame
  120.    structure of the "Multiprotocol Interconnect over Frame Relay" [4].
  121.  
  122.    The purpose of this specification is not to document what is already
  123.    standardized in [4].  Instead, this document attempts to give a
  124.    concise summary and point out specific options and features used by
  125.    PPP.
  126.  
  127.  
  128. 2.1.  Frame Format
  129.  
  130.    The full Q.922 header is easily combined with the smaller HDLC
  131.    header.  The fields are transmitted from left to right.
  132.  
  133.     0                   1                   2                   3
  134.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  135.    +-+-+-+-+-+-+-+-+
  136.    |  Flag (0x7e)  |
  137.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  138.    |         Q.922 Address         |    Control    |  NLPID(0xcf)  |
  139.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  140.    |         PPP Protocol          |
  141.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  142.  
  143.  
  144.    NLPID
  145.  
  146.       This field contains a one octet Network Layer Protocol Identifier
  147.       (NLPID), which identifies the network layer protocol encapsulated
  148.       over the Frame Relay virtual circuit, in accordance with the
  149.       Subsequent Protocol Identifier (SPI) in ISO/IEC TR 9577 [5].  The
  150.       value used for PPP is <TBD> CF hex.
  151.  
  152.    Protocol Field
  153.  
  154.       The Protocol field is two octets and its value identifies the
  155.       protocol encapsulated in the Information field of the frame.  The
  156.       field is transmitted and received most significant octet first.
  157.  
  158.  
  159. 2.2.  Modification of the Basic Frame
  160.  
  161.    The Link Control Protocol can negotiate modifications to the basic
  162.    frame structure.  However, modified frames will always be clearly
  163.    distinguishable from standard frames.
  164.  
  165.  
  166.  
  167.  
  168. Simpson                  expires in six months                  [Page 2]
  169. DRAFT                      PPP in Frame Relay                  July 1993
  170.  
  171.  
  172.    Address-and-Control-Field-Compression
  173.  
  174.       Because the Address and Control field values are not constant, and
  175.       are modified as the frame is transported by the network switching
  176.       fabric, Address-and-Control-Field-Compression MUST NOT be
  177.       negotiated.
  178.  
  179.    Protocol-Field-Compression
  180.  
  181.       When Protocol-Field-Compression is negotiated, both the NLPID and
  182.       Protocol fields are compressed.
  183.  
  184.       On transmission, when the Protocol field is compressed to a single
  185.       octet, the NLPID is omitted.
  186.  
  187.       On reception, the NLPID field is examined.  If it is not the PPP
  188.       NLPID value, then it is expected to be a valid PPP Protocol value.
  189.  
  190.       The Protocol field value 0x00cf is not allowed (reserved) to avoid
  191.       ambiguity when Protocol-Field-Compression is enabled.
  192.  
  193.  
  194. 3.  In-Band Frame Format Detection
  195.  
  196.    For Permanent Virtual Circuits (PVCs), the NLPID and PPP Protocol
  197.    fields easily distinguish the PPP encapsulation.
  198.  
  199.    Initial LCP packets contain the sequence cf-c0-21 following the
  200.    header.  When a PPP LCP Configure-Request packet is received, the PPP
  201.    link enters Link Establishment phase.
  202.  
  203.    When frames are detected which are not PPP encapsulation frames, they
  204.    MUST be handled according to [4].  However, once PPP has entered the
  205.    Link Establishment phase, such frames MUST NOT be sent, and on
  206.    receipt such frames MUST be silently discarded, until the PPP link
  207.    enters the Network-Layer Protocol phase.
  208.  
  209.    For those network-layer protocols which have no PPP Protocol
  210.    assignment, or which have not yet been implemented under the PPP
  211.    encapsulation, another method of encapsulation defined under [4]
  212.    SHOULD be used.
  213.  
  214.    When Protocol-Field-Compression is negotiated, others methods of
  215.    encapsulation defined under [4] MUST NOT be used.
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223. Simpson                  expires in six months                  [Page 3]
  224. DRAFT                      PPP in Frame Relay                  July 1993
  225.  
  226.  
  227. 4.  Out-of-Band signaling
  228.  
  229.    There is no generally agreed method of out-of-band signalling.  Until
  230.    such a method is universally available, an implementation MUST use
  231.    In-Band Frame Format Detection for both Permanent and Switched
  232.    Virtual Circuits.
  233.  
  234.  
  235. 5.  Configuration Details
  236.  
  237.    The accidental connection of a link to feed a Frame Relay multipoint
  238.    network SHOULD result in a misconfiguration indication.
  239.  
  240.    The following Configurations Options are recommended:
  241.  
  242.       Magic Number
  243.       Link Quality Monitoring
  244.       Protocol Field Compression
  245.  
  246.    The standard LCP configuration defaults apply to Frame Relay links,
  247.    except MRU.
  248.  
  249.    To ensure interoperability with existing Frame Relay implementations,
  250.    the default Maximum-Receive-Unit (MRU) is 1600 octets [4].  The basic
  251.    HDLC header is significantly shorter than the full-sized Frame Relay
  252.    header, which may give additional leeway in buffer management.
  253.  
  254.    The typical network feeding the link is likely to have a MRU of
  255.    either 1500, or 2048 or greater.  To avoid fragmentation, the
  256.    Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT
  257.    exceed 1500, unless a peer MRU of 2048 or greater is specifically
  258.    negotiated.
  259.  
  260.    Some early Frame Relay networks are only capable of 262 octet frames.
  261.    In order to operate PPP over a Frame Relay link, the minimum PPP MRU
  262.    of 1500 MUST be supported.
  263.  
  264.    To detect these inoperable links, the LCP Configure-Request packet
  265.    MUST be padded to the full 1500 octet length.  The padding MUST be a
  266.    sequence of octets beginning with 1, and ending with the number of
  267.    octets of padding.
  268.  
  269.    XID negotiation is not supported for PPP links.
  270.  
  271.    There is no need for Inverse ARP over PPP links.
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278. Simpson                  expires in six months                  [Page 4]
  279. DRAFT                      PPP in Frame Relay                  July 1993
  280.  
  281.  
  282. Security Considerations
  283.  
  284.    Security issues are not discussed in this memo.
  285.  
  286.  
  287. References
  288.  
  289.    [1]   Simpson, W. A., "The Point-to-Point Protocol (PPP)", work in
  290.          progress.
  291.  
  292.    [2]   International Telegraph and Telephone Consultative Committee,
  293.          CCITT Recommendation Q.922, "ISDN Data Link Layer Specification
  294.          for Frame Mode Bearer Services", April 1991.
  295.  
  296.    [3]   Simpson, W. A., "PPP HDLC Framing", work in progress.
  297.  
  298.    [4]   Bradley,  T.,  Brown, C., and Malis, A., "Multiprotocol
  299.          Interconnect over Frame Relay", RFC 1294, January 1992.
  300.  
  301.    [5]   ISO/IEC TR 9577, "Information technology - Telecommunications
  302.          and Information exchange between systems - Protocol
  303.          Identification in the network layer", 1990 (E) 1990-10-15.
  304.  
  305.  
  306. Acknowledgments
  307.  
  308.    This design was inspired by the paper "Parameter Negotiation for the
  309.    Multiprotocol Interconnect", Keith Sklower and Clifford Frost,
  310.    University of California, Berkeley, 1992, unpublished.
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333. Simpson                  expires in six months                  [Page 5]
  334. DRAFT                      PPP in Frame Relay                  July 1993
  335.  
  336.  
  337. Chair's Address
  338.  
  339.    The working group can be contacted via the current chair:
  340.  
  341.       Fred Baker
  342.       Advanced Computer Communications
  343.       315 Bollay Drive
  344.       Santa Barbara, California, 93111
  345.  
  346.       EMail: fbaker@acc.com
  347.  
  348.  
  349. Author's Address
  350.  
  351.    Questions about this memo can also be directed to:
  352.  
  353.       William Allen Simpson
  354.       Daydreamer
  355.       Computer Systems Consulting Services
  356.       P O Box 6205
  357.       East Lansing, MI  48826-6205
  358.  
  359.       EMail: Bill.Simpson@um.cc.umich.edu
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388. Simpson                  expires in six months                  [Page 6]
  389. DRAFT                      PPP in Frame Relay                  July 1993
  390.  
  391.  
  392.                            Table of Contents
  393.  
  394.  
  395.      1.     Introduction ..........................................    1
  396.  
  397.      2.     The Data Link Layer ...................................    2
  398.         2.1       Frame Format ....................................    2
  399.         2.2       Modification of the Basic Frame .................    2
  400.  
  401.      3.     In-Band Frame Format Detection ........................    3
  402.  
  403.      4.     Out-of-Band signaling .................................    4
  404.  
  405.      5.     Configuration Details .................................    4
  406.  
  407.      SECURITY CONSIDERATIONS ......................................    5
  408.  
  409.      REFERENCES ...................................................    5
  410.  
  411.      ACKNOWLEDGEMENTS .............................................    5
  412.  
  413.      CHAIR'S ADDRESS ..............................................    6
  414.  
  415.      AUTHOR'S ADDRESS .............................................    6
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.